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METHOD AND ARRftNOEMENT FOR TCP FLOW CONTROL 
Field of the Invention. 

5 

This invention relates to TCP (Transmission Control 
Protocol) flow control , and particularly (though not 
exclusively) to TCP flow control in wireless 
communication systems. 

10 

Background of the Invention 

TCP is a transport protocol in the internet protocol. 

15 suite (see for example,, the publication by W.R* Stevens, 
% TCP/IP illustrated, Volume Is The protocols', Addison- 
Wesley, Reading, Massachusetts, November 1994). It is 
used in applications such as telnet FTP (File Transfer 
Protocol) and HTTP (HyperText transfer Protocol) . TCP is 

20 designed for wire networks which have very low error 
rates . 

Flow control in TCP is governed by two windows: the 
sender's congestion window ('cwnd') and the receiver's 

25 advertised window (»awnd') . Flow control is based on the 
minimum of these 2 windows. The 'cwnd' is modified 
dynamically to match the capacity in the network- Most 
importantly it is reduced whenever packets are lost as 
this is an indication of congestion in the network. The 

30 *awnd' is based on the receiver's ability to buffer data 
that it receives and it can be dynamically reduced if the 
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receiver is unable to cope with the rate of reception of 
data* The initial value of *awnd' is controlled by 
parameters configured in the TCP protocol stack. 

5 As mentioned above, TCP is designed for low error rate 
networks. Therefore any packet losses which occur in TCP 
are regarded as due to network congestion and are 
therefore followed by a reduction in *cwnd' and 
consequently in the data rate of the sender as mentioned 

10 above. However, this is not appropriate to wireless 

networks which are inherently high error rate systems. 
Therefore, the 36PP (3rd Generation Partnership Project) 
standard provides ARQ (Automatic Repeat Request) 
functional ity, known as RLC (Radio Link Control - see, 

15 for example, the 3 GPP technical specification 3GPP TS 
25.322) that allows packets to be re -transmitted which 
have been subjected to error due to transmission over the 
air interface. However, the use of ARQ schemes result in 
the packets arriving out of order, so they have to be 

20 buffered before they can be passed on to TCP. The use of 
buffering introduces increased delay and this can result 
in increased RTT (Round Trip Time) • 

Assuming that the highest rate services are provided in 
25 the downlink, this means that large buffering is likely 
to be required in the network node, i.e., the RNC (Radio 
Network Controller} in the case of 3 GPP systems. The 
following considers this downlink (DL) problem. However 
the present invention is also appropriate for controlling 
30 uplink TCP flows. 
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The maximum DL rate specified in the 3 GPP technical 
specification 36PP TS 34.108 is 2Mbps. Assuming that it 
is not possible to alter the TCP protocol stack at the 
receiver (i.e., UBJ , it is therefore necessary that the 
UE must advertise a window at least equal to the 
bandwidth delay product appropriate for the 2Mbps 
service. If the UE is to support the maximum rate of 
2Mbps then the advertised window must be extremely large. 
If a smaller rate is then provided to the UE (due, for 
example, to the fact that many UE's are requesting 
service at the same time) then buffer overflow might 
occur. If buffer overflow does not occur the round trip 
time (RTT) will be very high since data will spend a long 
time buffered at the network node. 

High RTT will have a negative impact on performance 
perceived by the user. This is particularly true in the 
case of the user wishing to continue web browsing while 
downloading a large file via FTP; the web browsing 
session will appear to be extremely slow. Therefore we 
wish to provide a flow control technique to maintain a 
target RTT for any rate provided by the network while 
maintaining the ability to download data at rates up to 
the maximum 2Mbps rate. 

As mentioned previously, flow control is provided by the 
sender's % cwnd' and the receiver's ^awnd' , Since control 
of the sender's *cwnd' resides in the server, it can be 
located remotely and is not in any way controllable. It 
is therefore necessary that flow control is provided by 
the * a wild' „ 
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A number of schemes (discussed briefly below) for flow 
control have been suggested for TCP over 30 wireless 
systems. However, the issue with which these are most 
s concerned is preventing the buffer at the network node 
from overflowing (i.e., the sending node in the case of 
data download} . 

In the publication by Koga, Kawahara and Oie, "TCP flow 
10 control using link layer information in mobile networks 
Proceedings of SPIE Conference of Internet Performance 
and Control of Network Systems III, Boston, Massachusetts 
7, 2002, it is proposed that the receiver, i.e., the UE 
in the most likely case of file download, modifies the 
15 TCP window that it advertises based not on the capacity 
of the receivers buffers as is conventionally the case 
but on measures obtained from the RLC. This approach is 
extremely problematic since it means modification of the 
TCP protocol stack at the US and it may not be possible 
20 to obtain control of this stack. This is particularly 
true in the case where a PC (Personal Computer) is 
connected to a US (which acts effectively as a modem) and 
the TCP protocol stack resides in the PC. 

2S The publication by Seok, Joo and Xang, *A-TCP» A 

mechanism for improving TCP performance in wireless 
environments", IEEE broadband wireless summit. May 2001 
suggests a scheme whereby two entirely split connections 
are made, one between the server and the network node and 

30 another between the network node and the UE. This 

requires considerable additional complexity and may not 
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be of any benefit for- transfers using UDP (User Datagram 
Protocol) . 

The publication by BaJcre and Badrinth, «I-TCP» indirect 
5 TCP for mobile hosts" , Proceedings of the 15th 

International conference on distributed computer systems, 
May 1995, suggests modifying the TCP window size in TCP 
ACKe (ACKhowledge paclcets) . However in this publication 
the goal is simply to modify the TCP window size to the 
10 available buffer size at the network node. Limiting the 
buffer occupancy as in this publication does not 
guarantee a specified RTT. 

A need therefore exists for method and arrangement for 
15 TCP flow control wherein the above merit ioned 
disadvantage ( s) may be alleviated. 




Statement ©£ Invention 

20 

In accordance with the a first aspect of the present 
invention there is provided an arrangement for TCP flow 
control as claimed in claim 1. 

25 In accordance with the a second aspect of the present 
invention there is provided method for TCP flow control 
as claimed in claim 12. 
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Brief Description of the Drawings 

One method and arrangement for TCP flow control 
incorporating the present invention will now be 
5 described/ by way of example only, with reference to the 
accompanying drawing (a) , in which? 

FIS. 1 shows a block schematic diagram illustrating 
a 3 GPP radio communication system in which the 
10 present invention may be used? 



- 6 - 



FIG. 2 shows a block schematic diagram illustrating 
protocol architecture for U-plane showing functional 
location of a TCP window modification function based 
15 on the present invention; and 

FIG. 3 shows a block schematic diagram illustrating 
steps performed in the TCP flow control method 
between a server and a user equipment client 
20 terminal via a radio network controller. 



Description of Preferred Embodiment (b) 

2$ The following preferred embodiment of the present 

invention will be described in the context of a UMTS 
Radio Access Network (UTRANT) system operating in TDD 
mode. Referring firstly to PIG. 1, a typical < standard 
UMTS Radio Access Network (T3TRAN) system 100 is 

30 conveniently considered as comprising: a terminal /user 
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equipment domain 110; a UMTS Terrestrial Radio Access 
Network domain 120; and a Core Network domain 13 0, 

In the terminal /user equipment domain 110, terminal 
equipment CTE) 112 is connected to mobile equipment (ME) 
114 via the wired or wireless R interface. The MB 114 is 
also connected to a user service identity module (USXM) 
116; the ME 114 and the USIM 116 together are considered 
as a user equipment <UE> llB. The US 118 communicates 

10 data with a Node B (base station} 122 in the radio access 
network domain 120 via the wireless Ua interface. Within 
the radio access network domain 120, the Node B 122 
communicates with a radio network controller {RNC) 124 
via the JuJb interface. The RNC 124 communicates with 

15 other RNC s (not shown) via the lur interface* The Node B 
122 and the RNC 124 together form the UTRAN 126. The RNC 
124 communicates with a serving GPRS service node (SGSN) 
* 132 in the core network domain 130 via the Xu interface. 
Within the core network domain 130 r the SGSN 132 

20 communicates with a gateway GPRS support node CGGSN) 134 
via the Gn interface; the SGSN 132 and the GGSN 134 
communicate with a home location register (ffluR) server 
136 via the Gr interface and the Go interface 
respectively. The G6SN 134 communicates with public data 

25 network 13 8 via the Gl interface. 

Thus, the elements RNC 124, SGSN 132 and GGSN 134 are 
conventionally provided as discrete and separate units 
(on their own respective software /hardware platforms) 
ao divided across the radio access network domain 120 and 
the core network domain 130, as shown the PIG, 2. 
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The RNC 124 is the UTRAN element responsible for the 
control and allocation of resources for numerous Node B's 
122; typically 50 to 100 Node B's may be controlled by 
one RNC. The SNC also provides reliable delivery of user 
traffic over the air interfaces. RNC's communicate with 
each other (via the Xur interface) to support handover 
and macrodivereity. 

The SGSN 132 is the UMTS Core Network element responsible 
for Session Control and interface to the HLR. The SGSN 
keeps track of the location, of an individual UB and 
performs security functions and access control. The SGSN 
is a large centralised controller for many RNCs. 

The GGSN 134 is the UMTS Core Network element responsible 
for concentrating and tunnelling user data within the 
core packet network to the ultimate destination (e.g., 
internet service provider - ISP) . 

such a UTRAN system and its operation are described more 
fully in the 3 GPP technical specification documents 
3 GPP TS 25.401, 3GPP TS 23.060, and related documents, 
available from the 3GPP website at www.3gpp.org, and need 
not be described in more detail herein. 

In the present example, all functionality of the 
invention resides in the RNC 124 but can alternatively be 
applied at the UB 118. 
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Referring now to PIG. 2, as will be explained in greater 
detail below, in order to improve TCP flow for download 
of data to a OB 118 a modification 210 of the TCP window 
occurs at the radio bearer level, and is functionally 
located in the protocol architecture for the user plane 
(tf-plane) . In the RNC 124 and Node B 12 2 of the UTRAN 126 
TCP window modification 210 (which will be explained in 
greater detail below) is followed, by PDCP (Packet Data 
Convergence) processing 220, RLC (Radio Link Control) 
processing 230, MAC (Medium Access Control) processing 
240 and PHY (Physical layer) proceeding 250. It will be 
understood that the PDCP processing 220, RLC processing 
230, the MAC processing 240 are performed in accordance 
with the known 3GPP technical specifications TS 25 323, 
TS 25 322 and TS 25 321 respectively. PHY processing is 
described in 3<3PP technical specifications TS 25 2xx 
(e.g., 221, 222, 223, 224 & 225 for TDD). In all cases 
there is no need to describe these in further detail 
herein. 

The processed information is communicated across the 
wireless Uu interface to the UB 118, where complementary 
PHY processing 260, MAC processing 270, RLC processing 
280 and PDCP processing 290 are performed. As above, it 
will be understood that the PDCP processing 290, RLC 
processing 280, the MAC processing 270, and the PHY 
processing 260 are performed in accordance with the 
known 3GPP technical specifications TS 25 323 TS 25 322 
and TS 25 321 respectively, phy processing is described 
in 3GPP technical specifications TS 25 2xx (e.g., 221, 
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222/ 223, 224 & 225 for TDD). In all caaes there la no 
need to describe these in further detail herein. 

Referring now also to PIG. 3, TCP window modification 210 
& is based on the following steps: 

• At 310 , when a TCP packet (302) carrying data is 
received at RNC 124 from a server 140 for download 
to US 118 , a target buffer delay is specified and 
10 known, and a measurement of the delay within the 

transmit buffer of the RItC on downlink traffic is 
made. A TCP packet (304) carrying data is sent 
across the wireless Uu interface to the UE 118. 

• At 320, in the UE 118 an v awnd' value is calculated 
15 based on the UE receiver's buffer capacity and 

placed in the 'win' field in the ACK (ACKnowledge) 
packet (306) which is sent back to the RNC 124. 

• At 332-336, in the RNC 124 a new value of *a*md' is 
determined as follows: 

20 o at 332 , a target RLC buffer delay is subtracted 

from the ELC buffer delay measured at step 310, 
o at 334, a desired control loop gain multiplier 

is applied, and 
o at 336, the *awnd' value previously determined 
25 in the RNC 124 is added. 

• At 340, the next available SUU (Service Data Unit) 
containing a TCP ACK packet is identified. The *win' 
field value in the received ACK packet is compared 
with the value determined at step 330. If the value 

30 determined in step 330 is less than the *win' value 

in the received ACK packet then the f win' value in 

MWOjBS. .'27- Jun-05::08j 




« oun KUQ3 8:29PM. InetIP 



+44 CO) 14HO S6440S p. 15 



5 



10 



03.039-ipw 

-li- 
the packet ia replaced with that determined in step 
330. However, if the value determined in step 330 is 
greater than that in the received ACK packet no 
change ie made. 

• At 350, the TCP checksum is recalculated to take 
account of the modified TCP ACK. 

• At 360, the ACK packet is reconstructed and a TCP 
packet (30B> with modified ACK is sent to the server 
140. 

Mo more changes to the TCP window are made until all 
current data in the system has been ACKed {this can be 
measured conveniently by waiting until the number of ACKs 
reaches half the current number of SDUs in the system 
when the delayed ACK function is implemented in the TCP 
15 protocol stack) . 

It will be appreciated that since the RLC buffer delay 
parameters must be signaled through PDCP, the PDCP 
protocol layer could be considered a suitable location 
20 for this functionality to reside. 

It will be understood that ideally it would be desirable 
to measure overall round trip time (RTT) for a packet and 
accordingly implement flow control . However, in practice 
measuring the RTT based on ACK and SEQ numbering can be 
difficult since there are typically multiple TCP streams 
at any one moment. The total RTT is made up of the 
components shown in the following equations 

RTT - sender RLC buffer delay + sender to receiver 
air interface delay + reaeiver buffer delay + 
receiver to sender air interface delay. 



25 



30 
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The inventors of the present invention have realised 
that, assuming the volume of data associated with ACKs is 
low compared to data sent from sender to receiver, the 
5 receiver buffer delay can be affected by flow controlling 
the sender. Also, the time taken over the air interface 
{although variable due to retransmissions , etc.) can also 
be regarded as not affected by flow control- Therefore , 
all that needs to be monitored is the time an SDU spends 
10 in the RLC transmit queue. 

Also, simply measuring the time to traverse RLC transmit 
queue may be problematic since even when no new SDUs are 
added to the back of the queue the traverse time will be 
1S high for the last SDU. The following method is therefore 
conveniently used: 

1. For each SDU in the RLC transmit queue, 
measure s 

a. The current buffer size at the time when 
20 the SDU enter the RLC transmit queue • 

b. The time taken from the moment an SDU 
enters the RLC transmit queue to the 
moment it leaves the transmit queue (i.e., 
all PDU which make up the SDU have been 

26 sent at least once) . 

2* Determine the mean of a predetermined number of 
most recent SDUs for which the buffer size and 
buffer delay are available. 
3. If mean buffer delay is relatively close to 
30 (within a predetermined range about) target 

delay, 
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Modify TCP *awnd' window by an amount 
related to (target buffer delay - mean 
buffer delay) * control loop gain as in 
steps 332-336 of FIG. 3. Note that a 'dead 
5 band' , centred on desired target delay, 

may be applied where no adjustment is 
made . 

4. If mean buffer delay io considerably greater 
than (outside a predetermined range about) 

10 target delay, 

Adjust TCP window to the amount indicated 
by the current mean buffer size minus a 
predetermined quant ity. 

5. When a modification to the TCP window size is 
15 made no more changes are allowed to TCP window 

size until this change has taken effect. 

6. A minimum allowed calculated window can be 
configured, so that the determined TCP window 
size determined in stages 3 and 4 above cannot 

20 fall below this value. 



It will be appreciated that the process for TCP flow 
control described above will typically be carried out in 
software running on a processor (not shown) , and that the 

25 software may be provided as a computer program element 
carried on any suitable data carrier (not shown) such as 
a magnetic or optical computer disc. It will also be 
appreciated that the TCP flow control scheme described 
above may alternatively be fabricated in an integrated 

30 circuit for use in a terminal or RNC of a communication 
system. 
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It will be appreciated that although the TCP flow control 
scheme has been described above in the context of a 
downlink data transfer in a UTRA TDD system, the 
invention is not limited to such an application and may 
be used in downlink and/or uplink data transfer in 
communication systems generally. 

It will be understood that the method and arrangement for 
TCP flow control described above provides the advantage 
that RTT (i.e., the latency of the system) can be 
substantially guaranteed, irrespective of the throughput 
that the user is allocated. In comparison, it should be 
noted that using target buffer occupancy - as in the 
above-mentioned prior art publication "I-TCP: indirect 
TCP for mobile hosts" - does not allow the above 
condition to be met because buffer occupancy varies with 
throughput for a given RTT. 



20 
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Claims 



10 



15 



20 



25 



1. An arrangement for Transmission Control Protocol 
(TCP) flow control in a communication system, the 
arrangement comprising: 

means for determining delay in a transmit buffer of the 
system; and 

means for modifying TCP window size dependent on the 
determined delay. 

2. The arrangement of claim 1 wherein the means for 
modifying TCP window size comprises: 

means for sending to a TCP server of the system in an 
acknowledge packet an indication of modified TCP 
window size. 

3 . The arrangement of claim 1 or 2 wherein the means 
for modifying TCP window size comprises: 

means for determining a new TCP window size as a 

function of the determined transmit buffer delay 4 a 
target transmit buffer delay / and a previously 
determined TCP window size. 

4. The arrangement of claim 3 wherein the function is 
also a function of control loop gain. 

5. The arrangement of any one of claims 1-4 arranged to 
make, following a change in TCP window size, no further 
changes until receipt of a number of acknowledge packets 
substantially equal to half the current number data units 
in the system. 
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6. The arrangement of any one of claims 1-4 wherein the 
means for determining delay in a transmit buffer of the 
system comprises: 

means for determining mean buffer delay of a plurality 
of data units passing through the transmit buffer 
and for producing the determined delay as a function 
of the mean buffer delay. 

7. The arrangement of claim 6 arranged to modify TCP 
window sisae, if the mean buffer delay is within a 
predetermined range about a target delay, by an amount 
related to the difference between the mean buffer delay 
and the target delay. 



8. The arrangement of claim 7 arranged to modify TCP 
window size, if the mean buffer delay is outside a 
predetermined range about a target delay, by an amount 
related to difference between current mean buffer size 

20 and a predetermined value. 

9. The arrangement of any one of claims 1-6 comprised 
in a network controller of the system. 

25 10. The arrangement of any one of claims 1-9 wherein the 
system comprises a radio communication system. 

11. The arrangement of claim 10 wherein the radio 
communication system comprises a UTRAN system. 

30 
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12- A method fox Transmission Control Protocol (TCP) 
flow control in a comrrtunication system, the method 
comprising: 

determining delay in a transmit buffer of the system; 
& and 

modifying TCP window size dependent on the determined 
delay. 

13. The method of claim 12 wherein the step of modifying 
10 TCP window size comprises: 

sending to a TCP server of the system in an acknowledge 
packet an Indication of modified TCP window size. 

14. The method of claim 12 or 13 wherein the step of 
15 modifying TCP window size comprises: 

determining a new TCP window size as a function of the 
determined delay, a target transmit buffer delay, 
and a previously determined TCP window size. 

20 15* The method of claim 14 wherein the function is also 
a function of control loop gain. 

16. The method of any one of claims 12-15 comprising 
inhibiting making, following a change in TCP window size, 

25 no further changes until receipt of a number of 

acknowledge packets substantially equal to half the 
current number data units in the system. 

17. The method of any one of claims 12-15 wherein the 
30 step of determining delay in a transmit buffer of the 

system comprises: 



36 



S7 jun auua wjairn . incur 



03 .039-ipw 

- 18 - 

determining mean buffer delay of a plurality of data 
units passing through the transmit buffer and for 
producing the determined delay as a function of the 
mean buffer delay. 

5 

18. The method of claim 17 comprising modifying TCP 
window size, if the mean buffer delay is within a 
predetermined range about a target delay, by an amount 
related to the difference between the mean buffer delay 
10 and the target delay. 



19. The method of claim 18 comprising modifying TCP 
window size, if the mean buffer delay is outside a 
predetermined range about a target delay, by an amount 

15 related to difference between current mean buffer size 
and a predetermined value. 

20. The method of any one of claims 12-19 performed in a 
network controller of the system. 

20 

21. The method of any one of claims 12-20 wherein the 
system comprises a radio communication system. 

22. The method of claim 21 wherein the radio 
25 communication system comprises a UTRAN system. 

23. A computer program element comprising computer 
program means for performing substantially the method of 
any one of claims 12-22. 
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24. An integrated circuit comprising the arrangement of 
any one of claims 1-11. 

20. A method for TCP flow control substantially, as 

5 hereinbefore described with reference to the accompanying 
drawings . 

21. An arrangement for TCP flow control substantially as 
hereinbefore described with reference to the accompanying 

10 drawings . 
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Abstract 

METHOD AND ARRANGEMENT FOR TCP FLOW CONTROL 

5 

An arrangement (124} and method (310-360) fox 
Transmission Control Protocol (TCP) flow control in a 
communication system, by: determining delay ijn a transmit 
buffer of the system; and modifying TCP window size 
10 dependent on the determined delay. An indication of 
modified TCP window size is preferably sent to a TCP 
server <140) of the system in an acknowledge packet 
(310) . 

The invention is particularly suitable for TCP flow 
15 control in wireless communication systems (e.g., UTRA) 
systems,, and has the advantage that RTT (i.e., tbe 
latency of the system) can be substantially guaranteed, 
irrespective of the throughput that a user is allocated. 
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